查看原文
其他

两个bug导致谷歌云全球性瘫痪

2016-04-15 云头条

谷歌原以为只是一个局部性错误,没想到结果却演变成了一场覆盖所有区域的停运事件。




接踵而来的一连串问题起源于谷歌计算引擎(Google Compute Engine)的网络管理软件里面的两个错误(bug)。


如果你周一访问某些应用程序有困难,这问题很可能是谷歌的基础设施即服务(IaaS)解决方案谷歌计算引擎(Google Compute Engine)上出现一次短暂、但广泛的停运引起的。


如果影响了谷歌自己的产品,比如Gmail或Drive,哪怕小小的谷歌服务停运也会引起众人注意。而周一遭遇故障的是GCE,谷歌的这个基础设施支撑着公司企业和应用程序开发人员租用的虚拟服务器。


这次故障仅仅持续了18分钟,但是导致谷歌在所有区域的GCE实例无法使用。这对原以为谷歌的多区域数据中心会提供某种故障切换功能的客户来说显然不是什么好消息。


但是周一,客户们无法享用这种故障切换机制。这次故障解释了为何谷歌负责24x 7全天候服务的副总裁本杰明·特雷诺·斯洛斯(Benjamin Treynor Sloss)在周三特意写了一份异常详细的声明,解释故障原因。


斯洛斯说:“我们重视所有服务停运事件,但是我们对于同时影响多个区域的停运尤为关注,因为我们的客户很难缓解这类服务停运带来的影响。”


“这份事件报告比平常报告来得更全面、更详细,就因为我们认为4月11日的这起事件极其重要,我们希望大家明白这件事为什么会发生,我们对此采取了什么措施。”


简而言之,一个路由问题不仅让相关的VPN和第3层网络负载均衡系统陷入瘫痪,还让所有区域的GCE实例陷入瘫痪。


这次停运并没有影响到谷歌云平台(GCP)本身,但是确实影响到了GCP应用程序。作为补偿,受影响的GCP客户将获得服务积分,分别相当于GCE月费和VPN月费的10%和25%。


斯洛斯细述了一连串问题之所以接踵而来,归咎于其网络管理软件里面出现了两个错误(bug),工程师在网络上传播有缺陷的配置后,这两个软件错误使两套保障机制犯了错误。


据斯洛斯声称,就在停运前几小时,谷歌的工程师们从网络配置删除了一段未使用的GCEIP地址块,这种变更本身通常没有什么危险性。这些IP地址块让谷歌网络外面的系统可以找到GCP服务。


工程师们试图传播新的配置,而谷歌的网络配置软件当时检测到了这个配置存在问题,原因是“IP地址块删除出现了时间异常”。


但是由于维护软件存在的软件错误,它将所有的GCEIP地址块从新配置中删除,然后将新配置发布到网络上,而不是恢复到一种已知安全的配置。


失效的第二套保障机制是谷歌的“金丝雀步骤”(canarystep),要是没有第二个软件错误,它会确保新的配置被局限在一个站点,直到证明它安全,才会更广泛地部署开来。


“在这次事件中,金丝雀步骤正确地发现,新配置不安全。然而要命的是,管理软件中的第二个软件错误并没有将金丝雀步骤得到的结论传播回给发布进程,因而发布系统误以为新配置是有效安全的,于是开始逐渐部署开来。”


斯洛斯表示,这一系列系统错误意味着,到晚上7点09分(太平洋标准时间)也就是服务开始停运时,“从互联网进入到GCE的入站流量迅速丢失,丢失率达到了>95%。”


这时候,谷歌工程师才明白自己犯下了一个比较严重的错误,而仅仅20分钟之前,他们还以为自己查看的问题仅仅局限于谷歌的asia-east1VPN。到晚上7时21分,谷歌发布了警告,表明“其在所有区域遭到了严重的网络连接问题”。


斯洛斯表示,谷歌的工程师会在今后几周进一步做好预防、检测和缓解系统,以夯实其生产环境的保障机制。


云头条编译|未经授权谢绝转载


相关阅读:

谷歌承认最初的企业云战略有误,并解释为何改弦易辙

谷歌计划将所有内部IT系统迁移到云上

谷歌云计算服务迎来大捷 获苹果6亿美元服务合同

Spotify抛弃亚马逊 成为谷歌云服务大客户

别把宝都押在一家云服务提供商上!

宕机神马的Facebook也会搞不定......云计算没你想的那么强悍!

GitHub网站罢工:数据中心停电惹的祸!

亚马逊公司北弗吉尼亚数据中心因故停运

CloudHarmony:2014年云服务商的正常运行时间对比

十起最严重的云故障及教训

面对云故障  用户何以处惊不乱

公有云故障案例分析——Microsoft Azure的飞来人祸


喜欢八卦的你,欢迎加入,群主微信:aclood


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存